Los recursos diferidos probablemente sean añadidos en futuras actualizaciones de C#. Mientras que algunos están a favor, otros están en contra. Algunos incluso presentan estas objeciones:
Si el caso de uso para diferir es la limpieza de recursos, entonces los patrones diferidos son un antipatrón que no requiere se implemente IDisposable. La implementación de IDisposable permite que las herramientas adviertan si creamos una variable local desechable y luego nunca la desecha. Si acepta que los recursos no requieren IDisponible, pierde este beneficio.
Otra queja es que hace que el orden de las operaciones sea difícil de entender. Podemos tomar como base este ejemplo:
static void Main() {
Console.WriteLine("Hello"); //1
defer {
Console.WriteLine("Foo"); //5
}
defer {
Console.WriteLine("Bar"); //4
}
defer {
Console.WriteLine("Baz"); //3
}
Console.WriteLine("World"); //2
}
Como puedes ver, el código se ejecuta de arriba a abajo, omitiendo algunas líneas y luego de abajo a arriba.
Manejo de excepciones
Una pregunta discutida es cuál será el efecto de una excepción en un bloque de aplazamiento. Con un intento normal, el bloque actual finalmente se cancela, pero otros bloques que lo envuelven todavía se ejecutarán. ¿Sería ese el caso de la postergación o la primera falla causaría que los otros se omitieran? El consenso general parece ser que los bloques de aplazamiento restantes aún se ejecutarán.
Swift evita este problema al no permitir que el código que puede generar una excepción se llame desde un bloque de aplazamiento.
La propuesta de declaración diferida actualmente está etiquetada como un candidato de C#, pero eso no significa que realmente se eligió para ser parte de una futura versión de C#. Para que puedas dominar este tema de forma correcta, te animamos a tomar un curso de C#.
Adicionalmente, tomando en cuenta que VB y C# forman parte de .NET Core, también es recomendable que veas un curso de Visual Basic. Y para poder desarrollar aplicaciones que usen bases de datos puedes cursar un curso de MySQL.
